-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(sequencer)!: perform check tx like regular block building #1341
Conversation
I don't think this is the direction we want to go in, but some of what this achieves should be handled. Functionally for performance reasons with the new mempool design we want to have different levels of checks, to avoid DDOS at entry:
I believe some of this requires some memoization across the transaction since transactions are atomic, we need each action to be statically valid but also need the set to be valid. This requires some consideration across the transaction especially with regard to balances. There are other potential failures within a multi action transaction, but this is the primary concern. For some edge cases around changing sudo accounts the solution is likely to disallow those actions from being in a bundle. |
This PR is stale because it has been open 45 days with no activity. Remove stale label or this PR will be |
This PR was closed because it has been stale. |
Summary
This patch updates sequencer's mempool service to execute the same steps when serving an ABCI
CheckTx
request as it would during regular block building.Background
The current check-tx implementation was only performing a subset of the checks that would be performed during regular block construction (specifically, during finalize-block). This means that while a check-tx would return a positive response, a subsequent and immediate execution would fail. Furthermore, with the changes in #1318 the distinction between checks and execution has been lifted, moving the current check-tx implementation further away from actual business logic.
With this patch the check-tx logic now uses exactly the same code paths as for regular block construction.
This is done by creating a new
App
instance with a snapshot that never gets applied to the actual storage.Changes
App::execute_transaction
toApp::deliver_tx
: this moves the nomenclature closer to cometbft (and penumbra)App::deliver_tx_bytes
as a wrapper to the now privateApp:deliver_tx
.crate::service::Mempool
in terms ofApp::execute_transaction_bytes
App::deliver_tx_bytes
crate::mempool::Mempool
to requireArc<SignedTransaction>
in its methods: this is a relatively mild change because it wrapped its argument in anArc
anyway. This is useful becauseApp::execute_transaction_bytes
returns aArc<SignedTransacttion>
transaction::checks
Testing
ChecTx is now running the same logic as the rest of the app, which reduces the need for extra tests for the mempool service.
Tests were added for the following scenarios:
More test coverage is desirable but left to a future PR.
Metrics
Removed (at present, we no longer have direct access to these)
CHECK_TX_REMOVED_FAILED_STATELESS
CHECK_TX_REMOVED_STALE_NONCE
CHECK_TX_REMOVED_ACCOUNT_BALANCE
CHECK_TX_DURATION_SECONDS
with the following labels:CHECK_TX_STAGE => "stateless check"
CHECK_TX_STAGE => "nonce check"
CHECK_TX_STAGE => "chain id check"
CHECK_TX_STAGE => "balance check"
Added (this is a coarser metrics that effectively encapsulates those above):
CHECK_TX_REMOVED_SPECULATIVE_DELIVER_TX
CHECK_TX_DURATION_SECONDS
label:Renamed (describes better what happened and contrasting to the speculative metric above):
CHECK_TX_REMOVED_FAILED_EXECUTION
toCHECK_TX_REMOVED_FAILED_DELIVER_TX
Breaking Changelist
Related Issues
Closes #1340